home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-ietf-mhsds-convert-01.txt < prev    next >
Text File  |  1993-07-08  |  10KB  |  364 lines
  1.  
  2.  
  3.  
  4.  
  5. Network Working                                             S.E. Kille
  6. Group                                                 ISODE Consortium
  7. INTERNET-DRAFT                                               July 1993
  8.                                                 Expires:  January 1994
  9.  
  10.  
  11.  
  12.         MHS use of Directory to support MHS Content Conversion
  13.  
  14.  
  15.  
  16.  
  17.  
  18. Status of this Memo
  19. This document is an Internet Draft.  Internet Drafts are working
  20. documents of the Internet Engineering Task Force (IETF), its Areas,
  21. and its Working Groups.  Note that other groups may also distribute
  22. working documents as Internet Drafts.
  23. Internet Drafts are draft documents valid for a maximum of six months.
  24. Internet Drafts may be updated, replaced, or obsoleted by other
  25. documents at any time.  It is not appropriate to use Internet Drafts
  26. as reference material or to cite them other than as a ``working
  27. draft'' or ``work in progress.''
  28.  
  29. Please check the I-D abstract listing contained in each Internet Draft
  30. directory to learn the current status of this or any other Internet
  31. Draft.
  32. Abstract
  33. User Agents have various capabilities for support of multimedia
  34. messages.  To facilitate interworking between UAs of differing
  35. capabilities, it is useful for the MTS to be able to perform content
  36. conversion.  This document specifies an approach for X.400 Message
  37. Handling Systems to perform application level routing using the OSI
  38. Directory in order to support content conversion.  This document
  39. assumes MHS use of directory to perfom routing accoreding to ``MHS use
  40. of Directory to support MHS Routing'' [1].
  41.  
  42. This draft document will be submitted to the RFC editor as a protocol
  43. standard.  Distribution of this memo is unlimited.  Please send
  44. comments to the author or to the discussion group
  45. <mhs-ds@mercury.udev.cdc.com>.
  46.  
  47.  
  48.  
  49.  
  50. INTERNET--DRAFT            MHS Content Conversion            July 1993
  51.  
  52.  
  53. 1  Protocol Extensions
  54.  
  55. A number of protocol extensions are needed, primarily to support
  56. content conversion.  These extensions may be used with either MTA
  57. Abstract Service (P1) or MTS Abstract Service (P3).  The per-recipient
  58. extensions are given in Figure 1.
  59. The following per-recipient extensions are defined.
  60.  
  61.  
  62. general-explicit-conversion The explicit conversion of X.400 only
  63.     allows for a listed set of conversions.  This attribute allows for
  64.     any conversion of body parts to be requested.  Built in EITs must
  65.     be represented by their object identifiers.
  66.  
  67. content-conversion This requests for different content types to be
  68.     converted (e.g., content type 22 to 2 downgrade).
  69.  
  70. source-route This gives a sequence of points (either MTAs or MDs)
  71.     which must be traversed in the order given.  The points may be
  72.     accessed directly or indirectly for each step.  This should be
  73.     stripped as each point is reached.  If this element is marked as
  74.     critical for transfer, the route is mandatory, otherwise it is
  75.     advisory.  There is some risk of spurious loops being detected.
  76.     This can be specified by a UA or an MTA. An MTA may introduce
  77.     further source routing if a need arises.
  78.  
  79. route-barring This gives a list of points which must not be
  80.     traversed.  If this element is marked as critical for transfer,
  81.     the barring is mandatory, otherwise it is advisory.
  82.  
  83. route-restriction This give a list of points which the route must be
  84.     restricted to (e.g., to constrain costs).
  85.  
  86. The following per-message extensions are defined in Figure 2.  These
  87. are:
  88.  
  89.  
  90. warning-interval Some MTAs offer a facility to send (IPMS) warnings
  91.     about a messages delayed transit.  This parameter allows the
  92.     warning interval to be specified.
  93.  
  94. last-warning This parameter specifies the time at which the last
  95.     warning was sent.  It will ensure that warnings are sent to the
  96.  
  97.  
  98. Kille                                  Expires:  January 1994   Page 1
  99.  
  100.  
  101.  
  102.  
  103. INTERNET--DRAFT            MHS Content Conversion            July 1993
  104.  
  105.  
  106. _______________________________________________________________________
  107. general-explicit-conversion EXTENSION
  108.     GeneralExplicitConversion
  109.     ::= id-general-explicit-conversion
  110.  
  111. GeneralExplicitConversion ::= SEQUENCE {
  112.     from        ExternalEncodedInformationType,
  113.     to  ExternalEncodedInformationType }
  114.  
  115. content-conversion EXTENSION
  116.     ContentConverson                                                10
  117.     ::= id-content-conversion
  118.  
  119. ContentConversion ::= SEQUENCE {
  120.     from        ContentType,
  121.     to  ContentType }
  122.  
  123. source-route EXTENSION
  124.     SourceRoute
  125.     ::= id-source-route
  126.                                                                     20
  127. SourceRoute ::= SEQUENCE OF RouteElement
  128.  
  129. RouteElement ::= CHOICE {
  130.     mta [0]     DistinguishedName,
  131.     md [1]      DistinguishedName }
  132.  
  133. route-barring EXTENSION
  134.     RouteBarring
  135.     ::= id-route-barring
  136.                                                                     30
  137. RouteBarring ::= SET OF RouteElement
  138.  
  139. route-restriction EXTENSION
  140.     RouteRestriction
  141.     ::= id-route-restriction
  142.  
  143. RouteRestriction ::= SET OF RouteElement
  144.  
  145.  
  146.  
  147. _____________Figure_1:__Per-recipient_Protocol_Extensions______________
  148.  
  149.  
  150.  
  151. Kille                                  Expires:  January 1994   Page 2
  152.  
  153.  
  154.  
  155.  
  156. INTERNET--DRAFT            MHS Content Conversion            July 1993
  157.  
  158. _______________________________________________________________________
  159. warning-interval EXTENSION      -- interval between user warnings
  160.     INTEGER                     -- in minutes
  161.     ::= id-warning-interval
  162.  
  163. last-warning EXTENSION          -- time last warning was send
  164.     UTCTime
  165.     ::= id-last-warning
  166.  
  167. ______________Figure_2:__Per-message_Protocol_Extensions_______________
  168.  
  169.  
  170.     originator at even intervals.
  171.  
  172.  
  173. 2  Format Conversion
  174.  
  175.  
  176. An MTA will determine reformatting requirements for a message in two
  177. ways:
  178.  
  179. 1.  First, any explicitly requested conversions will be dealt with
  180.  
  181. 2.  Second, the recipients capabilities are determined (from the
  182.     directory), and any necessary conversions made.  UA capability may
  183.     be determined from any of:
  184.  
  185.      o  The User's entry
  186.  
  187.      o  The O/R Address entry
  188.  
  189.      o  A subtree capability restriction as defined in [1].
  190.  
  191.     A choice to do reformatting can only be made by an MTA with access
  192.     to this information.  Once an MTA has determined a requirement to
  193.     do reformatting, it should attempt to do this.  If this cannot be
  194.     done, or if the requirements are unknown, the message should be
  195.     routed without conversion.
  196.  
  197.  
  198. In many cases, the MTA will be able to perform conversion locally.  In
  199. some cases, particularly simple MTAs, it may be necessary to perform a
  200. conversion at a remote MTA. First the remote MTA must be identified.
  201. Each MTA will maintain a list of MTAs (or MDs??)  it uses for
  202. performing remote conversions.  Any MTA offering conversions will
  203.  
  204. Kille                                  Expires:  January 1994   Page 3
  205.  
  206.  
  207.  
  208.  
  209. INTERNET--DRAFT            MHS Content Conversion            July 1993
  210.  
  211. _______________________________________________________________________
  212. mTAUsedForConversion ATTRIBUTE
  213.     WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
  214.     ::= at-mta-used-for-conversion
  215.  
  216. bodyPartConversionService ATTRIBUTE
  217.     WITH ATTRIBUTE-SYNTAX GeneralExplicitConversion
  218.     ::= at-body-part-conversion-service
  219.  
  220. contentConversionService ATTRIBUTE
  221.     WITH ATTRIBUTE-SYNTAX ContentConversion                         10
  222.     ::= at-content-conversion-service
  223.  
  224. ______________Figure_3:__Format_Conversion_Registration________________
  225.  
  226.  
  227. register them in the directory.  Thus it is a matter of simple
  228. matching to determine if one of the MTAs used for conversion services
  229. offers the conversion needed (perhaps in more than one stage).  The
  230. attributes needed to do this are defined in Figure 3.
  231.  
  232. The attributes defined are:
  233.  
  234. mTAUsedForConversion This defines the set of MTAs which are used by
  235.     an MTA to provide conversion.
  236.  
  237. bodyPartConversionService This defines the services offered by an MTA
  238.     for body part conversion.
  239.  
  240. contentConversionService This defines the services offered by an MTA
  241.     for content type conversion (e.g., 22 to 2 downgrade).
  242.  
  243.  
  244. This facility can be used for either body part conversion or content
  245. type conversion.
  246. In some cases, the MTA performing the conversion will be accessed
  247. indirectly.  In this case, a mandatory source route should be
  248. specified, in order to ensure that the message is routed to the
  249. correct MTA.
  250.  
  251.  
  252. References
  253.  
  254. [1] S.E. Kille. MHS use of the directory to support MHS routing, July
  255.  
  256.  
  257. Kille                                  Expires:  January 1994   Page 4
  258.  
  259.  
  260.  
  261.  
  262. INTERNET--DRAFT            MHS Content Conversion            July 1993
  263.  
  264.  
  265.     1993. Internet Draft.
  266.  
  267.  
  268. 3  Security Considerations
  269.  
  270. Security considerations are not discussed in this INTERNET--DRAFT .
  271.  
  272.  
  273. 4  Author's Address
  274.  
  275.     Steve Kille
  276.     ISODE Consortium
  277.     PO Box 505
  278.     London
  279.     SW11 1DX
  280.     England
  281.  
  282.  
  283.     Phone:  +44-71-223-4062
  284.  
  285.     EMail:  S.Kille@ISODE.COM
  286.  
  287.  
  288.     DN: CN=Steve Kille,
  289.     O=ISODE Consortium, C=GB
  290.  
  291.     UFN: S. Kille, ISODE Consortium, GB
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310. Kille                                  Expires:  January 1994   Page 5
  311.  
  312.  
  313.  
  314.  
  315. INTERNET--DRAFT            MHS Content Conversion            July 1993
  316.  
  317.  
  318. A  Object Identifier Assignment
  319.  
  320.  
  321. _______________________________________________________________________
  322. mhs-ds OBJECT-IDENTIFIER ::= {iso(1) org(3) dod(6) internet(1) private(4)
  323.           enterprises(1) isode-consortium (453) mhs-ds (7)}
  324.  
  325. conversion OBJECT IDENTIFIER ::= {mhs-ds 7}
  326.  
  327. oc OBJECT IDENTIFIER ::= {routing 1}
  328. at OBJECT IDENTIFIER ::= {routing 2}
  329. id OBJECT IDENTIFIER ::= {routing 3}
  330.  
  331.                                                                     10
  332. oc-conversion-mta OBJECT IDENTIFIER ::= {oc 1}
  333.  
  334. at-body-part-conversion-service OBJECT IDENTIFIER ::= {at 1}
  335. at-content-conversion-service OBJECT IDENTIFIER ::= {at 2}
  336. at-mta-used-for-conversion OBJECT IDENTIFIER ::= {at 3}
  337.  
  338. id-alternative-address-information OBJECT IDENTIFIER ::= {id 1}
  339. id-content-conversion OBJECT IDENTIFIER ::= {id 2}
  340. id-general-explicit-conversion OBJECT IDENTIFIER ::= {id 3}
  341. id-logging-level OBJECT IDENTIFIER ::= {id 4}                       20
  342. id-route-barring OBJECT IDENTIFIER ::= {id 5}
  343. id-route-restriction OBJECT IDENTIFIER ::= {id 6}
  344. id-source-route OBJECT IDENTIFIER ::= {id 7}
  345. id-last-warning OBJECT IDENTIFIER ::= {id 8}
  346. id-warning-interval OBJECT IDENTIFIER ::= {id 9}
  347.  
  348.  
  349.  
  350. _______________Figure_4:__Object_Identifier_Assignment_________________
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363. Kille                                  Expires:  January 1994   Page 6
  364.